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(54) Method and system for optimizing performance and availability of a dynamic host 
configuration protocol (DHCP) service 



(57) The present invention discloses a method and 
system for monitoring and optimizing performance and 
availability of a Dynamic Host Configuration Protocol 
(DHCP) sen^ice provided by one or a plurality of DHCP 
servers (602) in an Internet Protocol (IP) network com- 
prising one or a plurality of IP subnetworks. 

The method comprises in a DHCP sewer (602) the 
steps of: 

• defining one or a plurality of groups of subnetworks, 
a group of subnetworks comprising one or a'pluraf- 
ity of subnetworks; 

• retrieving information related to resources, in par- 
ticular IP addresses, allocated within saki DHCP 
server to each group of subnetworks; 

• transferring satd informatkxi to a DHCP sen^ice 
monitoring system (600). 

The method comprises in a DHCP sendee monitor- 
ing system (403) the steps of: 

• retrieving (501 to 505) from one or a plurality of DH- 
CP sen/ers (401), informatnn related to resources, 
in particular IP addresses, allocated within each 
DHCP sender (401 ) to groups of subnetworks, each 
group of subnetworks comprising one or a pluarlity 
of subnetworks; 

• aggregating (506 to 511) the information for each 
group of subnetworks. 
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Description 

Technical field of the invention 

[0001] The present invention relates to computer net- 
works, and more particuiarly to a method and system in 
an Intemet Protocol (IP) network for optimizing perform- 
ance and availability of a Dynamic Host Configuration 
Protocol (DHCP) service provided by a plurality of DH- 
CP servers. 

Bocltground an 

INTERNET 

[0002] Intemet is a global network of computers and 
computers networks (the "Nef). The Internet connects 
computers that use a variety of different operating sys- 
tems or languages, including UNIX. DOS, Windows. 
Macintosh, and others. To facilitate and a)k>w the com- 
municatkxi among these various systems and languag- 
es, the Internet uses a language referred to as TCP/IP 
(•Transmission Control Protocol/Internet Protocol'). 
TCP/IP protocol supports three basic applk^atkxis on 
the Intemet: 

• transmitting and receiving electrons mail, 

• logging into remote computers (the 'Telnet'), and 

• transferring files and programs from one computer 
to another ('FTP' or 'File Transfer Protocol'). 

[0003] One of the object of TCP/IP is to interconnect 
networks and to provkJe an universal coownunkation 
services: an inter-network, or Intemet. Each physical 
network has its own technology-dependent communica- 
tion interface, in the form of a programming interface 
that provides basic communk:ation functions (primi- 
tives). Communication sendees are provkJed by a soft- 
ware that runs between the physkal network and user 
applications. This software provides a comrrxx) inter- 
face for these applications, independent of the underly- 
ing physical network. The architecture of the physical 
networks is hidden from the user. 
[0004] The Intemet protocol is still evolving through 
the mechanism of Request For Comments (RFC). New 
protocols (mostly applk:atk3n protocols) are designed 
and implemented by researchers. They are brought to 
the attention of the Intemet community in the form of an 
Intemet Draft (ID). The largest source of IDs is the In- 
ternet Engineering Task Force (IETF). 

IP ADDRESSES 

[0005] To interconnect two networks, a computer sys- 
tem able to forward packets from one network to the oth- i 
er is attached to both networks. Such a machine is called 
a router. The term 'IP router* is also used because the 
routing functkjn is part of the IP layer of the TCP/IP pro- 



tocol. 

[0006] IP addresses are used by the IP protocol to 
unk^uely identify a host on the Internet (Strctly speak- 
ing, an IP address klentifies an interface that is capable 

5 of sending and receiving I P datagrams, and one system 
can have multiple such interfaces. However, both hosts 
and routers must have at least one IP address, so this 
simplified definition is acceptable). IP datagrams (the 
base data packets exchanged between hosts) are 

'0 transmitted by a physk:al network attached to the host 
and each IP datagram contains a source IP address and 
a destination IP address. 

[0007] IP addresses are represented by a 32-bit un- 
signed binary value whk:h is usually expressed in a dot- 
's ted decimal format. For example. 9.167.5.8 is a valid In- 
ternet address. The numeric form is used by the IP soft- 
ware. The nr^apping between the IP address and an eas- 
ier-to-read symbolk: name, for example myhost.ibm. 
com, is done by the Domain Name System 

20 

IP SUBNETS 

[0008] Due to the expbsive growth of the Intemet. the 
principle of assigned IP addresses became too inflexible 
25 to allow easy changes to local network configuralwns. 
Those changes might occur when: 

• A new type of physical network is installed at a k> 
cation. 

^ • Growth of the number of hosts requires splitting the 
k)cal network into two or nfx>re separate networks. 

• Growing distances require splitting a network into 
smaller networks, with gateways between them. 

J5 [0009] To avoki having to request additbnal IP net- 
work addresses in these cases, the concept of subnets 
was introduced. The assignment of subnets can be 
done locally, as the whole network still appears to be 
one IP network to the outskie world. 

M> [0010] The host number part of the IP address is sub- 
divided again into a network number and a host number 
This second network is temped a subnetwork or subnet. 
The main network now consists of a number of subnets 
and the IP address is interpreted as: 

^ <nelwork numberxsubnet numberxhost 

number> 

[0011] The combination of the subnet number and the 
host number is often termed the local address or the lo- 
cal part. Subnetting is implemented in a way that is 

0 transparent to remote networks. A host within a network 
that has subnets is aware of the subnetting but a host 
in a different network is not; it still regards the local part 
of the IP address as a host number 
[0012] The diviskjn of the \oca\ part of the IP address 

5 into subnet number and host number parts can be cho- 
sen freely by the tocal administrator; any bits in the local 
part can be used to form the subnet. The division is done 
using a subnet mask which is a 32 bit number. Zero bits 
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in the subnet nnask indicate bit positions ascribed to the 
host number, and ones indicate bit positions ascribed to 
the subnet number The bit positions in the subnet mask 
belonging to the network number are set to ones but are 
not used. Subnet masks are usually written in dotted s 
decimal form, like IP addresses. 

DOMAIN NAMES 

[001 3] The host or computer names (like www.entre- io 
prise.com) are translated Into numeric Internet address- 
es (like 1 94.56.78.3). and vice versa, by using a method 
called DNS CDomain Name Service"). DNS is support- 
ed by network-resident senders, also known as domain 
name servers or DNS servers. is 

DYNAMIC IP 

[0014] There are generally three pieces of information 
needed by a system in order to be able to communcate '20 
on a TCP/IP network: 

• an IP address (to uniquely kientify the system on 
the network), 

• a subnet mask (to determine the network and sub- 2S 
net parts of the address), and 

• the address of at least one router (if the system is 
to be able to communicate with other devices out- 
side of its immediate subnet). 

30 

[0015] These three values represent the bare mini- 
mum of informatfon that must be programmed into each 
and every device for partcipating in the TCP/IP worW. 
Often the number of necessary parameters will be much 
higher. With the exponential growth rate of networking 3S 
today, it is easy to see that manual programming of 
these values into every device that is to attach to the 
network represents a major administrative worktoad. 
[0016] The increasingly nnoblle nature of the end us- 
ers also raises problems with regard to configuration of 40 
network devices. It is possible to alkxate multiple sets 
of configuration parameters to a device, but 

• this obviously means even wore worktoad for the 
administrator, 45 

• this is wasteful with respect to the number of IP ad- 
dresses allocated. 



concentrators and so on. It allows a minimum I P protocol 
stack with no configuratton informatton to obtain enough 
informatton to begin the process of downtoading the 
necessary boot code. BOOTP does not define how the 
downloading is done, but this process typically uses 
TFTP 'Trivial File Transfer Protocol (TFTP)" as de- 
scribed in RFC 906 - Bootstrap Loading Using TFTR 
Although still widely for this purpose by diskless hosts, 
BOOTP is also commonly used solely as a mechanism 
to deliver configuration informatton to a client that has 
not been manually configured. The BOOTP process in- 
volves the foltowing steps: 

• 1 . The client determines its own hardware address; 
this is normally in a POM (Read Only Memory) ori 
the hardware. 

• 2. A BOOTP client sends its hardware address in a 
UDP (User Datagram Protocol) datagram to the 
server. If the client knows its IP address and/or the 
address of the server, it should use them, but in gen- 
eral BOOTP clients have no IP configuratton data 
at all. If the client does not know its own IP address, 
it uses 0.0.0.0. If the client does not know the send- 
er's IP address, it uses the limited broadcast ad- 
dress (255.255.255.255). The UDP port number is 
67. 

• 3, The sewer receives the datagram and looks up 
the hardware address of the client In its configura- 
tton file, whtoh contains the client's IP address. The 
sender fills In the remaining fieWs in the UDP data- 
gram and returns it to the client using UDP port 68. 

• 4. When it receives the reply, the BOOTP client will 
record its own IP address and begin the bootstrap 
process. 

[0019] BOOTP is a draft standard protocol. Its status 
is recommended. The BOOTP specifications can be 
found in RFC 951 - Bootstrap Protocol. There are also 
updates to BOOTP, some relating to inter operability 
with DHCP (Dynamic Host Configuratton Protocol), de- 
scribed in RFC 1542 - Clarrffcatfons and Extensions for 
the Bootstrap Protocol, which updates RFC 951 and 
RFC 21 32 - DHCP Opttons and BOOTP Vendor Exten- 
skx)s. 



[001 7] Several components of TCP/1 P help automate 
device configuration, reduce the number of IP address- 
es alkxated, and/or cope with the demands of the mo- 
bile user. 

BOOTSTRAP PROTOCOL (BOOTP) 

[001 8] The BOOTP protocol was originally devetoped 
as a mechanism to enable diskless hosts to be remotely 
booted over a network as workstations, routers, terminal 



DYNAMIC HOST CONFIGURATION PROTOCOL 
50 (DHCP) 

[0020] The Dynamic Host Configuratton Protocol 
(DHCP) provides a framework for passing configuration 
informatton to hosts on a TCP/IP network. DHCP is 
55 based on the BOOTP protocol, adding the capability of 
automatto allocation of reusable network addresses and 
additional configuration options. DHCP messages use 
UDP port 67, the BOOTP sender's well-known port and 
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UDP port 68, the BOOTP client's well-known port. DH- 
CP consists of two components: 

• 1. A protocol that delivers host-specific configura- 
tion parameters from a DHCP Server to a host s 

• 2. A mechanism for the allocation of temporary or 
permanent network addresses to hosts. 

[0021] IP requires the setting of many parameters 
within the protocol implementation software. Because io 
IP can be used on many dissimilar kinds of network 
hardware, values for those parameters cannot be 
guessed at or assumed to have correct default values. 
The use of a distributed address allocation scheme 
based on a polling / defence mechanism, for discovery is 
of network addresses already in use, cannot guarantee 
unique network addresses because hosts may not al- 
ways be able to defend their network addresses. DHCP 
supports three mechanisnns for IP address allocatk)n: 

20 

• 1. Automatic allocation : DHCP assigns a perma- 
nent IP address to the host. 

• 2. Dynamic allocatkxi : DHCP assigns an IP ad- 
dress for a limited period of time. 

• 3. Manual alkjcation : The host's address is as- 2S 
signed by a network administrator. 

[0022] DHCP is a draft standard protocol. Its status is 
elective. The current DHCP specificatk>ns can be found 
in RFC 21 31 - Dynamk: Host Configuratk>n Protocol and 30 
RFC 2132 - DHCP Options and BOOTP Vendor Exten- 
sions. 



by the use of reasonably short lease times and the fact 
that mobile clients do not need to be allocated more than 
one address, to reduce the total number of addresses 
in use in an organization. However, the following shouW 
be conskjered when DHCP is being implemented: • 

• DHCP is built on UDP, which is, as yet, inherently 
insecure. In normal operation, an unauthorized cli- 
ent coukJ connect to a network and obtain a vald 
IP address and configuratkxi. To prevent this, it is 
possible to preallocate IP addresses to particular 
MAC (Medium Access Control) addresses (similar 
to BOOTP), but this increases the administratkxi 
worktoad and removes the benefit of recycling of 
addresses. 

• Unauthorized DHCP Servers couW also be set up, 
sending false and potentially disruptive informatkxi 
to clients. 

• In a DHCP environment where automatic or dynam- 
ic address allocatkxi is used, it is generally not pos- 
sible to predetermine the IP address of a client at 
any partk:ular point in time. In this case, if static DNS 
( Domain Name Server) servers are also used, the 
DNS senders will not likely contain valid host name 
to IP address nriappings for the clients. If having cli- 
ent entries in the DNS is important for the network, 
one may use DHCP to manually assign IP address- 
es to those clients and then administer the client 
mappings in the DNS accordingly. 



Configuration Parameters Repository 

[0023] DHCP provides persistent storage of network 
parameters for network clients. A DHCP Server stores 
a key-value entry for each client, the key being some 
unique identifier, for example an IP subnet number and 
a unique identifier within the subnet (normally a hard- 
ware address), and the value contains the configuratran 
parameters last allocated to this partcutar client. 
[0024] One effect of this is that a DHCP client will tend 
to always be allocated the same I P address by the send- 
er, provided the pool of addresses is not over-sub- 
scribed and the previous address has not already been 
alkxated to another client. 

DHCP Consktorations 

[0025] DHCP dynamic alkjcatksn of I P addresses and 
configuratkxi parameters relieves the network adminis- 
trator of great deal of manual configuration work. The 
ability for a device to be moved from network to network 
and to automatically obtain valid configuratk>n parame- 
ters for the current network can be of great benefrt to 
mobile users. Also, because IP addresses are only al- 
located when clients are actually active, it is possible, 



BOOTP and DHCP Inter operability 

3S [0026] The format of DHCP messages is based on the 
format of BOOTP messages, which enables BOOTP 
and DHCP clients to interoperate in certain circumstanc- 
es. Support for BOOTP clients at a DHCP Sen/er must 
be configured by a system administrator, if required 

40 

DYNAMIC DOMAIN NAME SYSTEM 

[0027] In order to take advantage of DHCP, yet still to 
be able to kxate any specific host by means of a mean- 
^ ingful label, such as its host name, the following exten- 
skxis to the Domain Name System (DNS) are required: 



A method for the host name to address mapping 
entry for a client in the domain name sen/er to be 
updated, once the client has obtained an address 
from a DHCP Sen/er. 



so 



ss 



A method for the reverse address to host name 
mapping to take place once the client obtains its ad- 
dress. 

Updates to the DNS to lake effect immediately with- 
out the need for inten^ention by an administrator. 
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• Updates to the DNS to be authenticated to prevent 
unauthorized hosts from accessing the network and 
to stop imposters from using an existing host name 
and remapping the address entry for the unsuspect- 
ing host, to that of its own. s 

• A method for primary and secondary DNS senders 
to quickly fon^rd and receive changes as entries 
are being updated dynamically by clients In short. 

a secure Dynamic Domain Name System (DDNS) w 
is necessary. 

[0028] In summary, in the DHCP and DDNS environ- 
ment. DHCP provdes a device with a valkj IP address 
for the point at which It is attached to the network. DDNS is 
provides a method of locating that devk:e by its host 
name, no matter where that device happens to be at- 
tached to a network and what IP address it has been 
alkx:ated. 

[0029] More explanatksns about the domain present- 20 
ed in the above sections can be found in the following 
publications incorporated herewith by reference: 

• TCP/IP Tutorial and Technical Overview by Martin 

W. Murhammer, Orcun Atakan, Stefan Bretz, l^rry 2S 
R. Pugh. Kazunari Suzuki, Davd H. V\foodpushibed 
by IBM International Technical Support Organiza- 
tkxi. 

• 'Internet in a nutshell* by \Aalerie Quercia, published 

by OReilly. October 1 997. 30 

PROBLEM 

[0030] The problem is to nrxxiitor the utilization of a 
Dynamic Host Configuration Protocol (DHCP) sen/ice 3S 
provided by one or a plurality of DHCP servers, in order 
tooptinrwily adjust configuration parameters. Due to the 
nature of DHCP protocol whk:h is based on UDP 
BOOTP broadcast, the DHCP service is provided to the 
DHCP Client by the fastest' DHCP Server to answer 40 
As a consequence, in a multiple DHCP Servers environ- 
ment, when a DHCP Server fails or when a DHCP Sew- 
er reachs its maximum capacity, the DHCP Sen/ers 
whch are still available continue to provkje a DHCP 
Sen/iceandtoanswerDHCPCIient requests. Theavail- ^ 
able DHCP Setwers continue to provide the sen^lce until 
they reach their maximum capacity. Eventually the DH- 
CP Service may fail because available DHCP Servers 
cannot support the total k>ad. 

[0031] A single DHCP Sen/er may be configured to so 
provide a DHCP Servce to multiple subnetworks or 
groups of subnetworks. In this case, the DHCP Server 
is configured with one pool of IP addresses per subnet- 
work. The capacity or size of a pool is defined by the 
number of IP adresses this pool can manage. S5 
[0032] In additran, for better resilience and better per- 
formance, a group of subnetworks can be administered 
by multiple DHCP Sen/ers. In this case, the DHCP Sen/- 



ice is provkjed by this plurality of DHCP Senders. 
[0033] Note : in the present invention, 'a group of sub- 
networks' comprises one or multiple subnetworks also 
called 'IP subnets' generally tocated in a same geo- 
graphical area. 

[0034] The problems are then to: 

• monitor the utilization of the DHCP Sennce for each 
group of subnetworks. 

• monitor the pools of I P addresses configured within 
each DHCP Server. 

• correlate and nrxxiitor for each group of subnet- 
works, the utilizatkxi of the pools of IP addresses 
configured on multiple DHCP Servers 

• detect any capacity problem on DHCP Servers, in 
order to antk:ipate any DHCP Service degradation 
or disruption. 

[0035] The DHCP Servk:e provided when one DHCP 
Sender has reached its maximum capacity is degraded 
because the DHCP Sen/ers whch are still available 
have to handle additional load. The nrxxiitoring of a DH- 
CP Sendee without analysis of its utillsatbn cannot not 
lead to an efficient anticipation of the problems, in par- 
ticular disrupton or degradation of the DHCP Servce. 

Objects of the invention 

[0036] 



• One object of the present invention is to provkie a 
method for optimizing performance and availability 
of a DHCP Sen/ice. 

• It is a further object of the present inventon to mon- 
itor the utilisation of a DHCP Sennce for each group 
of subnetworks. 

• It is another object of the present invention to rrx^n- 
itor the pools of IP addresses configured within 
each DHCP Sender. 

• It is yet another object of the present invention to 
correlate and monitor the utilizatran of the pools of 
IP addresses configured on multiple DHCP Sen/ers 
for each group of subnetworks. 

• It is yet another object of the present invention to 
detect any capacity problem on DHCP Servers. 

• It is another object of the present inventkxi to check 
that every DHCP Sen/er is correctly configured. 

Summary of the Invention 

[0037] The present inventkxi disctoses a method and 
system for monitoring and optimizing performance and 
availability of a Dynamk: Host Configuration Protocol 
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(DHCP) service provided by one or a plurality of DHCP 
servers in an Internet Protocol (IP) network comprising 
one or a plurality of IP subnetworks. 
(0036] More particularly the present inventk)n uses 
specific probes for collecting inforrnatwn related to the s 
utilization of IP address pools within said DHCP Send- 
ers. 

[0039] The present invention also uses a DHCP Serv- 
ice Utilisation application for correlating the information 
related to the utilizatbn of the IP address pools, and pro- io 
viding monitorhg reports and statistk:s. 
[0040] The method comprises in a DHCP sen/er the 
steps of: 

• definingoneorapluralityof groups of subnetworks, is 
each group of subnetworks comprising one or a plu- 
rality of subnetworks; 

• retrieving informatkxi related to resources, in par- 
tcular IP addresses, allocated within sakl DHCP 
server to each group of subnetworks; 20 

• transferring said informatbn to a DHCP semce 
monitoring system. 



[0041] The method comprises in a DHCP servwe 
monitoring system the steps of: 

• retrieving from one or a plurality of DHCP servers, 
informatbn related to resources, in particular IP ad- 
dresses, allocated within each DHCP server to 
groups of subnetworks, each group of subnetworks 
comprising one or a plurality of subnetworks; 

• aggregating the information for each group of sub- 
networks. 

[0042] The present inventions provides the following 

advantages: 

• Early detectk)n of IP address shortage in pools con- 
figured within each DHCP Sender for each group of 
subnetworks. 

• Early detectkyi of I P address shortage in pools con- 
figured on multiple DHCP Senders for each group 
of subnetworks. 

• Early detection of any capacity problem on DHCP 
Sen/ers for each group of subnetworks in order to 
antfcipate any servce degradatton or disruption. 

• Production of DHCP Service utilisatkxi reports, for 
adjusting configuration of DHCP Servers (for exam- 
ple, increase of the size of an IP address pool for a 
specific group of subnetworks on a DHCP Sen/er). 

• No additional or specifk: hardware is mandatory. 

Drawings 
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thereof, will best be understood by reference to the fol- 
k>wing detailed descriptbn of an illustrative detailed em- 
bodiment when read in conjunction with the accompa- 
nying drawings, wherein : 

• Figure 1 shows the IP address allocatran to a DHCP 
Client by a DHCP Sen/er according to prk>r art. 

• Ffgure2isaviewof a DHCPsen/erprobeaccording 
to the present inventkjn. 

• Figure 3 is a ftow chart of a DHCP sen/er probe ac- 
cording to the present inventk)n. 

• Figure 4 is a view of a DHCP group probe according 
to the present inventk)n. 

• Figure 5 is a flow chart of a DHCP group probe ac- 
cording to the present inventkxi. 

• Figure 6 is a physcal view of a DHCP sen/we mon- 
itoring system according to the present inventkin. 

Preferred embodiment of the hventlon 



[0044] The present inventkxi relates to the nnonitoring 
of a DHCP sen/kje and more partcularly to a method 
and system for checking the size of IP address pools for 
a group of IP subnetworks anrwng one or a plurality of 
30 DHCP sen/ers. The present invention Is based on the 
measure of utilizalron of IP address pools by means of 
probes. 
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IP ADDRESS ALLOCATION 



[0045] Figure 1 describes the DHCP Client/Sen/er in- 
leraclkxts when the DHCP Client does not know its net- 
work address. More partcularly. Figure 1 shows the ac- 
quisitbn mechanism by a DHCP Client of the IP address 

40 and the IP mininral configuration parameters from a DH- 
CP Server within an IP network. The DHCP Client (101 ) 
broadcasts a request on its local physfcal subnet (103). 
The request is f onwarded by any router having a BCOTP 
forwarding mechanism. When the request is received 

« by a DHCP Sen/er (102), the DHCP Sen/er checks 
whether it is able to answer the DHCP Client or not. If 
the DHCP Sen/er has still some available IP address 
within its address database, a positive answer is re- 
tumed to the DHCP Client. The DHCP Client selects the 

so first DHCP Sen/er for whfch a positive answer is re- 
ceived and confirms to this sen/er its agreement. 
[0046] More particularly the allocation of a new net- 
work address comprises the foltowing steps: 



[0043] The novel and inventive features believed ss 
characteristics of the invention are set forth in the ap- 
pended claims. The invention itself, however, as well as 
a preferred mode of use. further objects and advantages 



The DHCP Client broadcasts a request on its local 
physical subnet. The request may include some op- 
tions such as network address suggestion or lease 
duration. 
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• Each DHCP Server may respond with a message 
that includes an available network address and oth- 
er configuration options. The DHCP Server may 
record the address as offered to the DHCP Client 
to prevent the same address be'mg offered to other 
DHCP Clients in the event of further messages be- 
ing received before the first DHCP Client has com- 
pleted its configuration. 

• The DHCP Client receives one or more messages 
from one or more DHCP Servers. The DHCP Client 
chooses one based on the configuration parame- 
ters offered and broadcasts a message that in- 
cludes the DHCP Server identifier option to indicate 
which message it has selected and the requested 
IP address option, taken from the DHCP Client IP 
address in the selected offer. 

• The DHCP Servers receive the messages broad- 
casted by the DHCP Client. Those DHCP Sen/ers 
not selected use the message as notification that 
the DHCP Client has declined that DHCP Sender's 
offer The DHCP Sen/er selected in the message 
commits the binding for the DHCP Client to persist- 
ent storage and responds with a message contain- 
ing the configuratkDo parameters for the requesting 
DHCP Client. 

• The DHCP Client receives the message with con- 
figuratnn parameters and perfomras a final check on 
the parameters. At this point the DHCP Client is 
configured. 

INTERNAL VIEW OF A DHCP SERVER PROBE 

[0047] Figure 2 is a logical view of a DHCP Sender 
Probe (202). The DHCP Sen/er Probe runs concurrently 
with the DHCP Sender application (201). The DHCP 
Sen/er Probe (202) within the DHCP Sen/er (200) de- 
termines, the current number of alkxated IP addresses 
for each group of subnetworks and saves this informa- 
tion in a file (203) called "Sen/er Utilisation File' (in a 
preferred embodiment, there is one entry In the Sen/er 
Utilisatkdn File for each group of subnetworks). A group 
of subnetworks is in fact a list of IP subnetworks (or IP 
subnets) stored in a file (204) generally called 'Group 
File' (in a preferred embodiment, the file name is the 
group name for a better Identification of the informatkxi). 
A workstatkxi broadcasting an IP address alkDcatkxi re- 
quest from its local subnetwork, will be sen/ed by a 
unique DHCP Sen/er The Group File (204) in a DHCP 
Sen/er comprises in fact the list of IP subnetworks be- 
longing to a same group. 

DYNAMIC VIEW OF A DHCP SERVER PROBE 

(0048] Figure 3 is a flow chart of a DHCP Sen/er 
Probe as described in Figure 2. The DHCP Sender 
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Probe is executed at given and regular period of times. 
Information collected by the probe is recorded in a file 
(Sen/er Utilisation File - 203) containing for each group 
of subnetworks, the total number of IP addresses within 
the pool and the number of IP addresses used or alk>- 
cated. The process comprises the following steps: 

• (301 ) The Sen/er Utilization File in the DHCP Sen/er 
is opened. 

• (302) A test determines whether there is a Group 
File to process or not. 

• (31 3) I f there is no more Group File to process, 
the Sen/er Utilizatkxi File in the DHCP Sen/er 
is ck)sed. 

• If there is still a Group File to process: 

• (303) The group name is extracted from the 
Group File (in a preferred embodiment the 
group name is extrapolated from the Group 
File name). 

• (304) The list of subnetworks that belongs 
to the group is extracted from the Group 
File. 

• (305) A first counter called Total Group 
Pool Size counter* is initialized for the 
group. This counter is used to determine 
the total number of IP addresses that can 
be alkx:ated to this group (available and al- 
located IP addresses). 

• (306) A second counter called Total Group 
Pool Used counter' is initialized for the 
group. This counter is used to determine 
the total number of IP addresses actually 
alkxated to this group. 

• (307) A test determines whether there is a 
subnetwork within the group to process or 
not. 

• If there is a subnetwork to process: 

• (308) The size of the pool associ- 
ated with the subnetwork is re- 
trieved from the DHCP Server Ap- 
plicatkxi. 

• (309) The size of the pool is added 
to the Total Group Pool Size 
stored in the Total Group Pool Size 
counter 

• (310) The number of alkx:ated IP 
addresses associated with the 
subnetwork is retrieved from the 
DHCP Sen/er Application. 

• (311) The number of allocated IP 
addresses Is added to the Total 
Group Pool Used stored in the To- 
tal Group Pool Used counter 
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When all subnetworks have been 
processed: 

• (312) The Server Utilisation File is 
updated with the following infor- 
mation: 

• name of the group; 

• Total Group Pool Used; 

• Total Group Pool Size; . 

• a iwne stamp. 



DHCP GROUP PROBE 

[0049] Figure 4 is a view of a DHCP Group Probe 
(405). The probe can be processed either in a DHCP 
Monitoring System (403) or in any DHCP Sen/er The 
purpose of a DHCP Group Probe is to compute for each 
group of subnetworks administered by one or a plurality 
of DHCP Servers, the global utilisation of the IP address 
pools. The DHCP Group Probe collects the information 
previously processed by DHCP Server Probes on DH- 
CP Senders (401). 

• The inforn«t»n is stored in the Server Utilization 
File (402) of each DHCP Server (401 ) administering 
the group. 

• DHCP Servers are recorded in a list called "DHCP 
Sewers List File' (404). The collected information 
is then aggregated in several files (one per group) 
called 'Group Utilisation Files* (406). Each file con- 
tains all informatkxi related to the utilization of IP 
address pools for a given group, in particular the 
percentage of utilisatton of IP addresses. To avoid 
any IP address shortage in IP address pools, spe- 
cific actions (for instance, increase of a pool size in 
a DHCP Sen/er) can then be launched if, for in- 
stance, the computed percentage exceeds a pre- 
defined threshold. 

DYNAMIC VIEW OF A DHCP GROUP PROBE 

[0050] Figure 5 is a flow chart of a DHCP Group 
Probe. The probe is preferably executed at given and 
regular perkxJs of time. The information for each group 
of subnetworks is collected in the different DHCP Serv- 
ers. A file (404) in the DHCP Monitoring System (403) 
contains an exhaustive list of the DHCP Senrers admin- 
istering each group of subnetworks. The following proc- 
ess in the DHCP Monitoring System (403) is then exe- 
cuted: 

• (501 ) A DHCP Server (in a preferred embodiment, 
the DHCP Sen/er name, or address) is retrieved 
from the DHCP Servers List File (404). 

• (502) A test determines whether there is still a DH- 
CP Sen/er to process or not. 
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• If there is a DHCP Sen/er to process: 

• (503) A connection is established with the 
DHCP Sen/er (401). 

• (504) The Sen/er Utilisatkxi File (402) is re- 
trieved from the DHCP Sen/er. 

• (505) The connection with the DHCP Senr- 
er is terminated. 

• When there is no more DHCP Sen/er to proc- 
ess: 

• (506) An exhaustive list of the groups is ex- 
trapolated from the Sen/er Utilisation Files 
previously retrieved from DHCP Sen/ers 
(note each Sen/er Utilisation File contains 
group names, and a same group name 
may be present in multiple Server Utilisa- 
tion Files). 

• (507) A test determines whether there is 
still a group to process or not: 

• If there is still a group to process: 

• (508) Data for the group (Total 
Group Pool Used. Total Group 
Pool Size) are retrieved from 
Sen/er Utilisatkxi Files. 

• (509) The gtobal utilization of the 
IP address pools for the group is 
computed. In a preferred embodi- 
ment, the global utilisation is equal 
to sum of Total Group Pool Used 
variables, divkJed by sum of all To- 
tal Group Pool Size variables. 

• An action (for instance an alert) 
can be sent if a predefined thresh- 
old has been reached for this 
group. 

• (510) The gtobal utilisation of the 
IP address pools for the group is 
recorded with a time stamp. 

• (511) When there is no more 
group to process, a successful re- 
turn code is returned. 

DHCP SERVICE MONITORING SYSTEM 

[00S1] Figure 6 is a view of a DHCP Servtce Monitor- 
ing system (600) virithin an IP network. Adedcated com- 
puter system can be used to njn the DHCP Group 
Probes (601) and to collect the information located in 
each DHCP sen/er (602) by DHCP Sen/er Probes (603). 
[0052] While the inventkxi has been particularly 
shown and described with reference to a preferred em- 
bodiment, it will be understood that various changes in 
form and detail may be made therein without departing 
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from the spirit, and scope of the invention. of the preceding claims. 



Claims 



6. 



A method for monitoring and optimizing perform- 
ance and availability of a Dynamic Host Configura- 
tion Protocol (DHCP) service provided by one or a 
plurality of DHCP sen/ers (602) in an Internet Pro- 
tocol (IP) network comprising one or a plurality of io 
IP subnetworks, sakj method comprising in a DHCP 
server (602) the steps of: 

• defining one or a plurality of groups of subnet- 
works, each group of subnetworks comprising is 
one or a plurality of subnetworks; 

• retrieving infornnation related to resources, in 
particular IP addresses, allocated within said 
DHCP setyer to each group of subnetworks; 

• transferring said infonnnatk>n to a DHCP sen^lce 20 
monitoring system (600). 



2. The method according to the preceding claim 
wherein the step of retrieving informaton related to 
resources allocated to each group of subnetworks 
comprises the further step of: 

• determining a total number of IP addresses 
presently allocated to each group of subnet- 
works, the total number of IP addresses of a 
group of subnetworks being equal to the sum 
of IP addresses presently alkxated to each 
subnetwork defined within sakj group of sub- 
networks. 

3. The method according to any one of the preceding 
claims wherein the step of retrieving information re- 
lated to resources allocated to each group of sub- 
networks comprises the further step of: 

• determining a total number of IP addresses that 
can be potentially alkx^ated to each group of 
subnetworks, the total number of IP addresses 
of a group of subnetworks being equal to the 
sum of IP addresses that can be potentially al- 
located to each subnetwork defined within said 
group of subnetworks. 
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45 



4. The method according to any one of the preceding 
claims comprising the further step of: so ^•\ 

• storing the total number of IP addresses pres- 
ently allocated to each group and/or that can 
be potentially allocated to each group of sut>- 
networks in a file (203) within the DHCP sen/er. ss 

5. A system, in particular a DHCP server (200). adapt- 
ed for carrying out the method according to any one 



A computer readable medium comprising instaic- 
tions adapted for carrying out the method according 
to any one of steps 1 to 4. 

A method for monitoring and optimizing perform- 
ance and availability of a Dynamic Host Configura- 
tion Protocol (DHCP) service provWed by one or a 
plurality of DHCP senders (401) according to claim 
5 in an Internet Protocol (IP) network comprising 
one or a plurality of IP subnetworks, sakj method 
comprising in a DHCP sen^ice monitoring system 
(403) the steps of: 

• retrieving (501 to 505) from one or a plurality of 
DHCP servers (401 ). information related to re- 
sources, in particular IP addresses, alkjcated 
within each DHCP server (401) to groups of 
subnetwori<s, each group of subnetwori^s com- 
prising one or a plurality of subnetworks; 

• aggregating (506 to 511) said information for 
each group of subnetworks. 

The method according to the preceding claim 
wherein the retrieved infomiation comprises for 
each DHCP sewer a total number of IP addresses 
presently alkx^ted to each group of subnetworks, 
the total number of IP addresses of a group of sut>- 
networi^s in a DHCP server being equal to the sum 
of IP addresses presently allocated to each subnet- 
work defined within sakj group of subnetworks. 

The method according to any one of claims 7 to 8 
wherein the retrieved information comprises for 
each DHCP server a total number of IP addresses 
that can be potentially alkx:ated to each group of 
subnetworks, the total number of IP addresses of a 
group of subnetworks in a DHCP server being equal 
to the sum of IP addresses that can be potentially 
allocated to each subnetwork defined within said 
group of subnetworks. 



10. The method according to any one of claims 7 to 9 
comprising a first step of: 

• recording sakj one or plurality of DHCP servers 
in a list (404); 
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9. 



The method according to any one of claims 7 to 1 0 
wherein the step of aggregating (506 to 511) saki 
inforrratlon for each group of subnetworks compris- 
es the further step of: 

• building (506) a list of groups of subnetworks 
using information retrieved from DHCP serv- 
ers. 
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12. The method according to any one of claims 7 to 11 
wherein the stop of aggregating (506 to 511) said 
information for a group of subnetworks comprises 
the further step of: 



18. 



A computer readable medium comprising instmc- 
tions adapted for carrying out the method according 
to any one of steps 7 to 16. 



determining a total number of IP addresses 
presently allocated to said group of subnet- 
works on all DHCP servers, the total number of 
IP addresses being equal to the sum off IP ad- 
dresses presently alkDcated to sakj group of 
subnetworks in each DHCP sender. 
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13. The method according to any one of claims 7 to 12 
wherein the step of aggregating (506 to 511) said 
infomration for a group of subnetworks comprises is 
the further step of: 

• determining a total number of IP addresses that 
can be potentially allocated to said group of 
subnetworks on all DHCP senders, the total 20 
number of IP addresses being equal to the sum 

of iP addresses that can be potentially alkxat- 
ed to sakj group of subnetworks in each DHCP 
server. 

2S 

14. The method according to any one of claims 7 to 1 3 
wherein the step of aggregating (506 to 511) said 
infomnation for a group of subnetworks comprises 
the further step of: 

30 

• divkiing the total number of IP addresses pres- 
ently allocated to said group of subnetworks on 
all DHCP servers by the total number of IP ad- 
dresses that can be potentially alkx:ated to said 
group of subnetworks on all DHCP sewers; 3S 

• comparing the result of the division with a pre- 
determined threshokl; 

• triggering a corrective actkxi when this thresh- 
old is reached for a group of subnehworks. 

40 

15. The method according to any one of claims 7 to 14 
wherein the step of triggering a corrective actton 
comprises the further step of: 



• triggering an alert; or/and 4S 

• adjusting within one or a plurality of DHCP serv- 
ers the number of IP addresses that can poten- 
tially be allocated to sakj group. 

1 6. The method according to any one of claims 7 to 1 5 so 
wherein the step of retrieving informatkxi is execut- 
ed at predefined or/and regular periods of time on 
request of the DHCP sen/ice monitoring system 
(403). 

55 

17. A system, in partk:ular a DHCP service monitoring 
system (403) adapted for carrying out the method 
according to any one of claims 7 to 16. 



10 



EP 1 079 583 A1 

IP Address Allocation 



DHCP DHCP 
Server Server 
(102) (102) 



IP Network 



DHCP 
Client 
(101) 



DHCP 
Client 
(101) 



DHCP 
Client 
(101) 



FIG.1 



11 



EP 1 079 583 A1 



DHCP Server Application 



DHCP Server Application 
(201) 




DHCP Server (200) 



FIG. 2 



12 



EP 1 079 583 A1 



Close Server 
Utilization File 



(313) 



DHCP Server Probe 



open Server Utilization File . J 
130 1 )l 



No 




Extract Group name from Group File 
(3031 



Extract Subnet list from Group File 
(3041 



Write Group utilization data 
into Server Utilization File: 
Group name 
Total Group Pool used 
Total Group Pool Size 
Timestamp ^^g^ 




Get Pool Size from DHCP Server 



application for this subnet 



(308) 



Add Pool Size to Total Group 
Pool Size 



(309) 



get number of used IP address, from DHCP 
Server application, for this Subnet (31 0^ 






Add number of used IP addresses to 

Total Group Pool ^3-,-!^ 







FIG. 3 



13 



EP1 079 583A1 



DHCP Group Probe 




FIG. 4 



14 



EP 1 079 583 A1 



DHCP Group Probe 



Build an exhaustive list 
of Groups, using the 
Server Utilization Files 
(506) 



Extract utilization 
data for the Group, 
from all Server Utilization 
File s (508) 



Compute the global 
utilization data 

(509) 



Get DHCP Server from DHCP 

Servers List File (spi^ 



No 





Connect to DHCP Server 
^503) 1 



Get Server Utilization File 
from DHCP Server ( find) 



Timestamp and record 
the global utilization 
data (51 0) 



Disconnect to DHCP Server 
. (505)1 



Return code OK 
(511) 



FIG. 5 



IS 



EP 1 079 S83 A1 



DHCP Service Monitoring System 



DHCP 
Server 
(602) 



Server 
Probe 
(603) 



DHCP 
Server 

(602) 



Server 
.Probe 
(603) 




DHCP Service 
i\^onitoring System 
(600) 



DHCP 
Client 



DHCP 
Client 



DHCP 
Client 



FIG. 6 



16 



EP 1 079 563 A1 



0 



Europctn Prteni 
Otflce 



EUROPEAN SEARCH REPORT 



EP 99 48 0077 



DOCUMEWTS COHSIDEBED TO BE RELEVANT 



CKalion oldbcuriwil witti indlcaten. 
ofratMHi 



CUKSS9KAJKHOFim 
APPUCA-nOI antCU) 



'IP AddressMorks- 
0NSI6TH SOLUTIONS. 'Online! 1998, 
XP002129978 

Retrieved from the Internet; 

<UR L : h t tp : //tmw . i pworks . n 1 /i pai#-spd . htm> 

* retrieved on 2000-02-07? 

* the whole document ♦ 

WO 99 33211 A (U S WEST INC ;I1EDIA0NE 
GROUP INC (US)) 1 July 1999 (1999-07-01) 

* page 5, line 10 - page 14, line 15 ♦ 

DROMS R: "Automated configuration of 
TCP/IP with DHCP- 

IEEE INTERNET CORPUTING. JULY-AUG. 1999, 
IEEE, USA, 

vol. 3, no. 4, pages 45-53. XP000874503 
ISSN: 1089-7801 

* the whole dociosent * 



The presont sascti rapcrt has been dmmt up loi afl cUns 



THE HAGUE 



8 February 2000 



1-13.17 
18 



14-16 
1-18 



H04L29/06 
H04L12/24 



H04L 



CATEGORY OF CITED DOCUMEhfTB 

X : partiouiarlif relevant if tAhen Akvw 
Y rpankMafVroiMam If oomtinsdwlin another 
docunenl of the aame eolBgoty 



RAMIREZ DE ARa.., F 



T : twry Of prtnc^e wKJwIyInQ tw fcwwiion 
E : eerter pnent doajrr«t. but piiiMMd ov or 
liter Tv fBfriQ dace 

D:doc umen cindir.tg^T^aftfn 
L '. docufneiTt ched tor other msons 



O : non-wittten (tedaeiA 



docufncfit 



17 



EP 1 079 583 A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPUCAT10N NO 



EP 99 48 0077 



08-02-2000 



PAMdDOMiwnl 
dM hi Minii ripoit 



Public^ion 



WD 9933211 A 01-07-1999 US 6009103 A 28-12-1999 



e 

o 

Si For 



18 



